The present invention generally relates to data processing in telecommunications systems and more specifically to separating route tables between data planes in a data structure and distributing different parts of the data structure to different data planes.
A split-plane architecture includes a control plane and one or more data planes. The data planes include virtual or physical circuits that route data for various applications, such as asynchronous transfer mode (ATM) circuits, Internet protocol (IP) route and bridging tables, and point-to-point protocol (PPP) sessions.
Each data plane includes a number of ports. A port on one data plane may exchange data with another port on the same data plane or a port on a different data plane. The control plane maintains a route table that includes the routes from a source data plane to a destination data plane. The routes are used by the data planes to determine where to send data. For example, a source data plane sends data received at a port to another port on the same data plane or a different data plane according to a route in the route table.
When a data plane crashes, data cannot be routed to the failed data plane or else a system failure may occur. Thus, the control plane should clear any routes that route data to the failed data plane in the route table. This may be referred to as “clearing the data plane”. When the failed data plane becomes operational again, the control plane should restore the routes from the working data planes (those that did not fail) to the restarted data plane in the route table. Also, the routes from the restarted data plane to the working data planes should be restored. This is referred to as “data plane resynchronization”. All of the above changes should also be communicated to the data planes.
Accordingly, when one of the data planes crashes, the control plane updates the routes for the other data planes so data is not transferred to the failed data plane. If the routes are not updated, errors may occur when data is transferred to a failed data plane. Also, when the failure condition is restarted, the control plane should update the routes for the restarted data plane so the restarted data plane can transfer data to the other data planes. Further, when the failure condition is restarted, the control plane restores the routes for the other data planes so that the other data planes transfer data to the restarted data plane. The control plane communicates all the above changes to the data planes.
Having the control plane as the central manager of the route table causes many problems when data planes fail. The route table typically includes a high number of routes. Thus, a lot of messaging between the control plane and other data planes is required in order to clear and resynchronize the data planes. For example, a split-plane architecture may include 16,000 point-to-point sessions distributed across all the data planes. The control plane becomes a bottleneck of the system because a large number of messages are required to clear or resynchronize the data planes. For example, applications running on the control plane may be blocked due to the resynchronization activity performed by the control plane whenever a data plane crashes and whenever a crashed data plane is restarted. The problem increases in complexity with respect to the number of data planes in the system. The more the number of data planes, the more resynchronization the control plane has to do. This in turn means that as the number of data planes increases, the processing the control plane needs to perform to resynchronize the data planes increases. Also, the number of messages the control plane needs to send increases as the number of data planes increases.